Gremlinのカオスエンジニアリングを効果的に実践するための基礎コースで学んだことまとめ1 ~ 目標を達成するための技術的及びビジネスイニシアティブ ~

#Gremlin

#カオスエンジニアリング

森亮介

2021.11.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

先日、Gremlin®でカオスエンジニアリングを効果的に実践するための基礎を学ぶコースを受ける機会があったので、その中でカオスエンジニアリング実戦における 技術的及びビジネスイニシアティブの理解　という内容が非常に勉強になったのでまとめていきたいと思います。

カオスエンジニアリングの最大の目標

最大の目標は信頼性の向上。そのためにアプリケーションやシステムがエラー/故障をどのように処理するかどうかテストすることが重要である。

明確に定義された目的とKPIを持ち、構造的で組織的なアプローチをとる必要がある。何の指示も監督もなく無作為にカオスエンジニアリングの実験を行っても、実用的な結果は得られず、システムを不必要なリスクにさらすことになります。

この目標を達成するための考え方として、

技術的イニシアティブとビジネスイニシアティブ

があります。

イニシアティブっていろんな意味があって使い方が難しい単語ですが、ここでは目標を達成する取り組み　という意味で使っていきます。

技術的イニシアティブとは

一般的な技術的イニシアティブの例ですが、

冗長化・フェイルオーバー　(Redundancy / Failover)
モニタリングの検証 (Validating Monitoring)
データ完全性 (Data Integrity)
インフラストラクチャの適切なサイジング (Right-sizing Infrastructure)
自動スケーリング (Autoscaling)
負荷分散 (Load Balancing)
高可用性 (High Availability)

があります。

エンジニアリングチームは、以下のような短期的な運用目標に関心を持ちます。

ダウンタイムや障害復旧にかかる時間の削減
オンコールのインシデントや深夜の通知数の削減
変更に伴う障害発生率の低減
信頼性のテストを積極的に行うことで、アプリケーションの移行速度を向上させる

カオスエンジニアリングを行うことにより、上記の運用目標にも役立つ知見を得ることができます。

インシデントの削減、オンコールの負担軽減、システムの故障に関する理解の向上、システム設計の改善、SEVの平均検出時間の短縮、SEVの繰り返し発生の減少　といったことです。

※ SEV(インシデント)

ビジネスイニシアティブとは

一般的なビジネスイニシアチブの例ですが、

アップタイムの最大化 (Maximizing Uptime)
セキュリティ (Security)
コンプラ (Compliance)
ピーク時のトラフィックへの対応　（Preparing for Peak Traffic)
クラウドへの移行　（Cloud Migrations)
コスト最適化　(Cost Optimization)
ビジネス継続性　　（Business Continuity)

があります。

経営陣は、以下のような長期的なビジネス志向の目標に関心を持ちます

新製品の発売を確実に成功させる
お客様の満足度や製品の使用率を低下させる、コストやダメージの大きいダウンタイムを回避すること
信頼性や安定性の問題によるリリース遅延の削減
保守作業、再作業、技術的負債の削減
エンジニアリングの生産性と変更速度の向上

こういった目標を達成するためにカオスエンジニアリングが役立ちます。

収益とメンテナンスコストの極めて大きな損失を防ぎ、より幸せでより熱心なエンジニアを生み出し、エンジニアリングチームのオンコールトレーニングを改善し、会社全体のインシデント管理プログラムを改善することができる　

といったことがカオスエンジニアリングを実施することにより得られるとされています。

検討すべき目標について

組織としてカオスエンジニアリングを始める際には、どのような目標を立てるのかを検討しないといけません。

採用プロセスの指針となったり、より高い信頼性を提供するための歩みを追跡できます。

どういった目標にすればいいかわからない時は、過去1年に経験したインシデントを思い返せば良いと言われています。

以下のような質問が役に立ちます。

障害の内容は？　ハードウェアの故障？　依存関係の問題？　人が起こした障害ですか？
どのシステムが影響を受けましたか？一時的に利用できなくなったのか、完全にオフラインになったのか？通常のサービスに戻すのにどのくらいの時間がかかりましたか？
お客様への影響はどうでしたか？ダウンタイムやデータ損失が発生しましたか？カスタマーサポートチームでは、それに伴ってチケットが増加しましたか？
運用チームはどのくらい早くインシデントに気付きましたか？自動化された監視ソリューションによって検出されたのか、それとも誰かがそれに気づいたのか？オンコールのスタッフを準備していましたか、それとも対応チームを急遽編成する必要がありましたか？
インシデントの解決にはどのくらいの時間がかかりましたか？障害を解決または軽減するための自動化されたシステムはありましたか？バックアップから復元する必要がありましたか？
問題はどのように解決されましたか？本番環境にしか存在しないその場しのぎの修正でしたか、それとも修正プログラムをコードベースにマージしましたか？その修正を文書化しましたか？

答えがない、もしくは答えに困ったものに焦点を当ててみましょう。

以下のような例が挙げられていました。

自動化された監視システムがインシデントを検出できなかった　-> オンコールチームに通知できなかった

といった場合だと、インシデントに至るまでの状況を再現することで、警告のしきい値をテストすることが目的の1つとなる。

これにより、問題を解決できるだけでなく、監視システムの詳細や、閾値を最適に調整する方法を知ることができます

目標達成のための進捗管理

行っている取り組みが目標に向かっているかどうかを判断するにはどうすればいいのでしょう？

それにはシステムの内部状態を測定して追跡し続ける必要があります。　この内部状態を測定することを観測性といい、観測性に使われるメトリクスを収集することで性能、容量、スループットなど、システムのさまざまな属性を定量化できます。

現在のデータだけでなく、過去のデータと比較することで変化をすることもできます。

ただし、現代のシステムはマイクロサービス化などにより複雑になってきていて、観測可能なデータを片っ端から集めると、すぐに情報過多になってしまいます。大規模なシステムだと、ゴールデンシグナルと言われている4つのデータ（レイテンシー、トラフィック、エラーレート、リソースの飽和）を追跡することも大変な作業になってしまいます。

なので、目的に直接関連するメトリクスを収集することに集中することが大事とされています。